Add the two remaining fields that the search reducer manages but the
type previously elided: suggestedFields (initialised to [] and
populated by SUGGESTED_FIELDS_GET_RECEIVE) and searchFailed (toggled
by SEARCH_GET_REQUEST and SEARCH_FAILURE). The TODO comment is
removed since the omitted fields are now declared.

The shape of currentQuery remains { q: string } even though the
reducer actually stores the full search-query payload there;
tightening that is a separate concern.

The page and pageSize URL params have always been strings at runtime
(URL query parameters are inherently strings, and every call site in
the frontend passes string literals like "1" or option values like
"25"). The types previously claimed number in three places, which
forced consumers to either cast at the call site or absorb a
silently-wrong type.

Three coordinated fixes, all narrowing types to match the runtime:

- updatePage / updatePageSize action creators now take string.
- The corresponding action payload types in GiantActions drop their
  any annotations in favour of string.
- UrlParamsState.pageSize moves from number to string, matching the
  already-string UrlParamsState.page.

No behavioural change. The reducer was already storing whatever the
action carried.

The backend search endpoint has always returned pageSize in its
response, and the search reducer reads action.searchResults.pageSize
when computing total pages. The TS type omitted the field, so any
consumer reading currentResults.pageSize tripped a TS2339 in strict
projects.

Add the field to both the TypeScript type and the corresponding
PropTypes shape.

Pure types-only migration: same class structure, same lifecycle, same
methods. Adds a Props interface and an internal InputSupperHandle type
for the ref. PropTypes are removed since the TS interface supersedes
them.

One trivial dead-code drop: the original focus()/select() guarded on
this.searchInput !== document.activeElement, but searchInput holds a
React component instance, not an HTMLElement, so the comparison was
always true. The accompanying "value reset" hack set .value on the
same React instance, which had no effect. Simplified to a plain
null-check; observable behaviour is identical.

Pure types-only migration: same class structure, same lifecycle
methods (componentDidMount, UNSAFE_componentWillReceiveProps,
componentDidUpdate, componentWillUnmount), same _debounce class field,
same connect() + bindActionCreators wiring. Adds StateProps,
DispatchProps, and SearchState interfaces; replaces PropTypes with
those interfaces; uses ThunkDispatch in mapDispatchToProps so the
thunk action creators type-check.

Three small drops, each behaviour-preserving:

- The `addQuery={this.addQuery}` prop passed to <SearchBox>: this.addQuery
  was never declared on the class (always undefined at runtime), and
  SearchBox didn't declare or use the prop either. Dead on both sides.
- The renderControls <Select> components previously passed value as a
  plain string. react-select v1's @types declare value as ValueType
  (an option object), so we look up the current option from the
  options array and pass that. At runtime react-select v1 resolves a
  string the same way; the option lookup is the type-honest
  equivalent.
- searchResultsPropType and suggestedFieldsPropType imports are
  dropped along with the PropTypes block they fed.

The class-based structure is intentionally preserved; converting to
hooks-and-functional form is a separate concern and would happen in
a follow-up PR.

The debounced text updater dispatches updateSearchText(text) and then
calls triggerSearch(this.props.urlParams). The dispatched action
updates urlParams.q asynchronously, so the immediate triggerSearch
call was using the stale q from before the user typed — searching
with empty/old text. Pressing Enter a second time worked because by
then the dispatched state had landed.

Pass the freshly-typed text in the query object directly so the
search fires with the user's actual input on the first Enter.